1. Field of the Invention
The present invention relates generally to managing transactions made up of one or more program functions running within a middleware container environment, and more specifically to monitoring behavior of the transactions.
2. Description of the Related Art
As competition increases between business organizations, each organization tends to focus on objectives that include reducing cost, adapting rapidly to change in the business environment, and improving customer satisfaction. To accomplish these objectives more business transactions are becoming electronically automated. As a result, managing the transactions in a timely manner by utilizing a middleware container, for example, a transaction server, a web server, or Enterprise JavaBean (EJB) container is a critical aspect for business continuity.
A transaction is one or more program functions (i.e., program code) to perform a group of tasks, and execution of the transaction can be managed within a middleware container. A task is a method, operation, process, or step to implement an objective of the transaction. The objective of the transaction may include electronically transferring money from bank account X to bank account Y, electronically ordering an item from an online catalog, or calling another transaction that performs another objective. Moreover, a middleware container is typically a software component that offers a variety of application architectural services to the end-user. The architectural services offered by the middleware container to the end-user can include beginning a transaction, committing a transaction, rolling back a transaction, and data synchronization.
It is known for a software developer to write program code to implement a transaction that is hosted within the middleware container. In addition, for complex software applications, a software developer may write program code to implement a transaction that utilizes other transactions, including those from third parties.
It is also known for a middleware container to identify that a task of a transaction is failing by tracking the amount of time to complete the task, and then determining whether the amount of time to complete the task exceeds a pre-determined threshold value (i.e., timeout value) defined by a system programmer/administrator. Specifically, if the amount of time to complete the task exceeds the pre-determined threshold value, then the task and corresponding transaction are considered to be failing and are identified. However, it is difficult for the middleware container to identify a failing transaction in a situation where the amount of time for each task of the transaction to complete does not exceed the pre-determined threshold value, but the combination of each task running in a sequence loops endlessly without terminating. A transaction having a combination of tasks that loops endlessly without terminating, is considered a failing transaction.
Furthermore, it is also known for transaction servers to utilize pre-determined threshold values (i.e., timeouts values) as baselines for determining whether a transaction is successfully completed. However, utilizing pre-determined threshold values as baselines for determining whether the transaction completes successfully can be complicated in scenarios where the transaction interacts with multiple other transactions. Specifically, in scenarios where the transaction interacts with multiple other transactions it can be difficult to determine which of the transactions are actually failing successful completion, because the pre-determined threshold values may not accurately reflect the expected behavior of the transactions. Thus, the challenge of managing a transaction hosted within a middleware container, and identifying whether the transaction is considered as failing, continues to persist.